As used herein, workflow means the organization of processes into a well-defined flow of operations to fulfill a business need. A process means a defined series of tasks to be completed in stages where data is forwarded to an appropriate member of a workgroup for each task resulting in a final workflow data. As used herein workgroup means a plurality of users, each having a computer connected to one or more other users within the group by a network, and where the plurality of users communicate through the network to accomplish a defined series of tasks to produce a final workflow product.
Workflow products need a mechanism to enforce a policy on a given workflow in order to ensure that the workflow consistently complies with a given standard or expectation. One example of this would be a workflow that violates organizational security policies by using credentials (user id/pass) to login to a target server instead of Secure Sockets Layer (SSL) certificates. Another example is the Global Solutions Directory (GSD) Universal Management Infrastructure (UMI) requirement to audit workflows based on a particular security policy or set of rules for items such as error handling and best coding practices. Other examples include validation of workflows based on execution of error handling, best coding or implementation practices.
Policy in workflow typically exists around what one can do to a resource within the workflow, but not to the workflow itself. The majority of current solutions manually inspect the workflows prior to making them available to the workflow engine for execution. There is, at present, no capability to automatically ensure policy enforcement immediately prior, during and at completion of a workflow execution.
Carlos Ribeiro and Paulo Guedes of IST/INESC Portugal, in “Verifying Workflow Processes against Organization Security Policies,” disclose “a static analyzer that automatically verifies the consistency between workflow specification written in WPDL (Workflow Process Definition Language) and organization security policies . . . .” Specifically, the authors seek to show how an SPL (security language) specification can be checked against a WPDL workflow specification. (see http://www.inesc-id.pt/pt/inidadores/Ficheiros/1164.pdf). Douglas Long, Julie Baker, and Francis Fung of Odyssey Research Associates, in “A Prototype Secure Workflow Server” disclose their prototype policy editor, workflow server, and underlying Java-based implementation for workflow policies that provide “fine grained dynamic access and control.” (see http://www.atc-nycorp.com/papers/LONG_ACSAC_SecureWorkflow.pdf). The IBM Tivoli Access Manager for Business Integration provides, inter alia, centralized administration of both access control and data protection services across mainframe and distributed servers. (see http:/www-306.ibm.com/software/tivoli/products/access-mgr-bus-integration).
The above solutions focus on policy driven secured access to the resources within a workflow at the time of access. Moreover, these solutions focus on security, but do not address elimination of some or all manual inspection of workflows for compliance with business policies (such as, but not limited to, error handling, best coding or implementation practice policies). Moreover, these solutions cannot verify that the workflow itself is free from tampering at any given point in execution. What is needed is a system and method to process workflows of varying formats and standards for compliance with security and business policies. What is further needed is a mechanism to provide warnings during the processing of the workflow so that remedial action can be completed as a prerequisite to validation of the workflow.